1.         Subscriber
2.         Publisher
3.         Broker

Mooie, technische termen met een hoog vraagtekengehalte, waarvan de leek al snel denkt “zo, dat klinkt moeilijk!”. Gelukkig valt dat, zoals met veel dingen die moeilijke namen hebben, best wel mee.

MQTT versus Facebook
Je kunt MQTT vergelijken met een discussiegroep of debat. Binnen zo'n groep zijn er allemaal mensen met meningen over verschillende onderwerpen (topics). Als iedereen maar over elk onderwerp van alles mag roepen en vinden, luistert er niemand naar elkaar en krijg je een soort Facebook effect, waarbij er allemaal comments worden gegeven op onderwerpen. In een discussiegroep is er vaak een leider, degene die het gesprek begeleidt en zorgt dat iedereen aan de beurt komt over het betreffende onderwerp, verschillende ontwerpen aan bod komen en het onderwerp nog te volgen is (dat zou voor social media soms ook wel handig zijn... ;-)).

MQTT werkt net zo. De gespreksleider is de MQTT broker. De groep mensen bestaat uit publishers en subscribers. Een persoon, of in MQTT land een apparaat, kan zowel publisher en/of subscriber zijn. Alle onderwerpen of topics gaan via de broker. Een apparaat kan zich inschrijven voor een bepaald topic bij de broker en kan zelf topics aanmaken bij de broker. 

Voorbeeld:
Apparaat 'temperature sensor' is een publisher en heeft een bericht voor de broker:

topic:”temperatuur_woonkamer”; “value: 22.5”.

Het apparaat stuurt dit bericht één keer per minuut uit, waarin “value” uiteraard de actuele waarde is. De broker slaat dit bericht op en overschrijft deze als er een nieuw bericht met hetzelfde topic binnenkomt.

Elk apparaat wat geïnteresseerd is in de temperatuur van de woonkamer, stuurt een subscribe bericht naar de broker voor het topic “temperatuur_woonkamer”. Zodra de broker een nieuw bericht binnenkrijgt van een apparaat met het topic “temperatuur_woonkamer”, stuurt de broker dit bericht door naar elk apparaat wat zich ingeschreven heeft op dit topic.

Een apparaat kan zowel een publisher, een subscriber, of beide zijn. Nu hebben we een voorbeeld van één sensor met één apparaat. Maar stel je hebt een heel flatgebouw of industriële hal, waar elk apparaat zowel waardes geeft, als waardes wilt weten van de overige apparaten. Dan kan elk apparaat zijn waarde wegsturen, “publishen”, onder zijn eigen topic en elk apparaat kan op dit topic inschrijven. Je kunt als apparaat zelfs inschrijven op je eigen topic. Dan ontvang je de berichten die je zelf stuurt. Klinkt onzinnig, maar is wel handig om te weten of het systeem goed werkt. Zeker tijdens prototypen is dat prettig.

Rol van de broker
Als de broker er niet zou zijn, zou elk apparaat alle berichten van elke sensor moeten ontvangen en moeten besluiten om er iets mee te doen, of het bericht te negeren. Dit zou resulteren in een overbelaste buffer en grote kans dat een apparaat niet de berichten ziet die hij zou moeten zien. Beetje zoals Facebook, waarbij de nuttige comments bedolven raken in de opmerkingen die er wat minder toe doen. 

Wat doet Domoticz met MQTT?
Wat Domoticz met MQTT doet staat netjes omschreven in de handleiding: https://www.domoticz.com/wiki/MQTT

Het huis
In de handleiding staat dat Domoticz met maar 2 topics werkt. Voor ingaand en uitgaand verkeer (domoticz/in en domoticz/out). Om MQTT bij Domoticz te gebruiken is het van belang dat de broker geïnstalleerd wordt, zoals omschreven in de handleiding. Ik maak hier gebruik van de Mosquitto broker die, volgens mijn favoriete werkwijze, natuurlijk open-source is. Deze broker is op dezelfde Raspberry Pi geïnstalleerd als waar de Domoticz server op draait. De afbeelding hierboven laat zien wat voor berichten er achter het topic kunnen worden geplaatst.

Alle communicatie van en naar Domoticz staat in de log. Hier kun je zien welke apparaten een verbinding maken, wat voor berichten ze sturen en onder welke topic. Ook uitgaand verkeer vanaf Domoticz wordt weergegeven. In dit geval is de Raspberry Pi de hardware die zowel de Domoticz server draait (een apparaat die published en subscribed) en de broker is. Deze 2 moeten wel los van elkaar gezien worden! 

MQTT en Arduino
Afijn. Dat was Domoticz. Nu de Arduino nog. Hoe gaat deze om met de MQTT berichten? Hoe is de Arduino op het netwerk gekoppeld? Met de welbekende Ethernet Shield van Arduino. Hier zit een chip op (W5100 of W5500) die via de SPI verbinding van de microcontroller met een TCP/IP stack kan communiceren. Technische details zie:

-        https://wizwiki.net/wiki/doku.php?id=products:w5500:start
-        https://store.arduino.cc/arduino-ethernet-shield-2

Om de Arduino de MQTT berichten te laten begrijpen, heb ik de MQTT <pubsubclient.h> bibliotheek hieronder gebruikt:

https://pubsubclient.knolleary.net/api.html 

Via deze bibliotheek kan de Arduino zich inschrijven op topics en zelf berichten publishen via de Ethernet Shield. Enige voorwaarde voor Domoticz is wel dat de interne buffer voor berichten in de header file naar een hogere waarde wordt gezet, want de berichten van Domoticz zijn te lang. Klein detail waar ik wel even zoet mee was... gevalletje RTFM (!), want het staat op pagina 1 van de bovenstaande link.

Terwijl ik dit schrijf, merk ik dat dit onderwerp best lang duurt en ik misschien iets teveel in detail treed, maar we zijn er bijna!

Om de berichten van Domoticz te kunnen interpreteren in de Arduino, heb ik een aantal functies geschreven die de berichten uit de buffer leest en interpreteert. Als er nuttige informatie staat, geeft de functie deze informatie terug en worden de betreffende uitgangen aangestuurd. De 'idx' wat een specifiek adres is van een schakelaar of lamp, de 'nvalue' wat aan of uit betekent, en de 'svalue' wat een waarde tussen de 0 – 100% weergeeft. Deze functies staan hieronder ter referentie.

De aannemer en de elektrische installatie
Ik besef me dat de bovenstaande uitleg best gedetailleerd is en allicht voor sommige lezers niet zo interessant. De MQTT communicatie voor elkaar krijgen was echter wel een behoorlijk omvattend en belangrijk deel, waar dan ook veel tijd in is gaan zitten.

Om dit verhaal wat te compenseren wil ik je ook nog wat andere belangrijke informatie delen: de aannemer! Een nieuwbouwhuis bouwen is een bijzondere ervaring. Je betaalt zeer waarschijnlijk het hoogste bedrag wat je ooit in je leven uit zult geven, om een stuk modder te kopen waar je vanaf uur 1 al WOZ-waarde over moet betalen en daarna talloze gesprekken aan moet gaan met (onder)aannemers die gevoelsmatig belachelijke prijzen rekenen. In ons geval vier partijen alleen al voor de badkamer. Als je afwijkt van de standaard kijkt men moeilijk, moet je het zelf maar regelen. Dan zul je zelf ook de vergunningen aan moeten vragen om het voor elkaar te krijgen.

Met andere woorden: een avondje uit eten geeft je meer het “klant is koning” gevoel dan wanneer je een paar ton uit geeft aan grond en stenen. Op zich was dit niet heel verrassend, gezien je dit weet uit verhalen van anderen, maar als je na het hele traject even een stapje terug doet om te kijken wat er nu eigenlijk gebeurd is, vind ik het wel een fascinerende wereld, die bouw. Hoofd koel houden en rustig doorgaan. Gevalletje “pick your battles” zeg maar.

Ondertussen is het laatste obstakel genomen: de aannemer voor de elektrische installatie. Om mijn domotica straks netjes te kunnen installeren, heb ik op een aantal punten wat extra leidingen en dozen nodig, maar vooral belangrijk is dat er vanaf elke centrale doos in het plafond een extra loze leiding naar de meterkast moet lopen.

Ik moet eerlijk toegeven toen ik de offerte zag, inclusief het meerwerk, heb ik wel getwijfeld om dit door te zetten. De prijs dekte een groot deel van de kosten van een bestaande “plug and pray” domotica installatie. Maar wie A zegt moet ook B zeggen. Al heb ik het geheel beperkt tot de benedenverdieping en de installatie buiten, om toch de kosten wat te drukken. Zie onderstaande plattegrond voor de elektrische installatie op de begane grond.

What’s next?
Je hebt ondertussen een hoop informatie gelezen deze keer! Voor het vervolg van mijn DIY domotica project is het een cruciale stap om de communicatie op orde te krijgen. De volgende keer zal ik wat luchtigers op het menu zetten en wil ik uitleggen hoe ik de elektronica op het hardware vlak wil beveiligen. Tot dan!

Lees ook de eerder verschenen blogs van Jan-Jelle:

Blog 1: Nieuwe resultaten bij ROV SCADA-systeem afstudeerproject
Blog 2: Domotica en waarom ik het graag wil toepassen
Blog 3: Specificaties, prototyping en dimmen van mijn nieuwe ledverlichting